Distinguish OpenAI batch timeout and cancellation in deferrable tasks - #72149

The synchronous path cancels the batch before raising a timeout, but the
deferrable path only failed the task and left the batch running and billing on
OpenAI's side. A deferred timeout now requests cancellation with the batch id
carried by the trigger event. Cancellation is asynchronous, so the batch
reports "cancelling" for a while before it settles; a cancel that fails is
logged and never masks the timeout.

Deliberately not cancelling on a polling_error: batches.cancel is
irreversible, and the failure mode there is unknown and often a transient,
Airflow-side error rather than a real batch problem. OpenAI's batch has a
24-hour completion window that bounds it on its own, so leaving it alone costs
a bounded amount; wrongly cancelling it is unrecoverable data loss. Anthropic
cancels on its equivalent error branch, but its session has no such natural
end point, so that precedent does not apply here.

Every TriggerEvent OpenAIBatchTrigger yields sets batch_id from a required
constructor argument, and OpenAITriggerBatchOperator only ever defers to that
trigger, so the branch that logged "carried no batch_id" could not be reached
and had no test covering it. The batch id is now read the way the success path
in the same method already reads it, with event["batch_id"], so the two paths
are consistently defensive.

OpenAITriggerBatchOperator.on_kill and OpenAIHook.wait_for_batch's timeout
branch both called cancel_batch bare, so an error from the cancellation request
propagated in place of the reason the task was actually stopping. on_kill now
goes through _cancel_batch_quietly, and the synchronous timeout path logs a
warning and still raises OpenAIBatchTimeout. Both paths now behave the way the
deferred timeout path already did.

The trigger wrote termination_reason as a bare string and the hook keyed its
exception map on bare strings, so a typo on either side type-checked fine and
only a test could catch it. Both sides, and the operator's timeout check, now
go through TerminationReason, making a misspelled reason an attribute error.
The enum subclasses str, so the value crossing the triggerer boundary is
unchanged and the existing tests still pin it.

The note that a deferred timeout now raises OpenAIBatchTimeout was lost in a
rebase. It is back as a warning that spells out OpenAIBatchTimeout is not an
OpenAIBatchJobException, so handlers keyed on the latter stop matching. Both
notes from this change now sit above the 2.0.0 heading, since 2.0.0rc1 was
cut without it.

The timeout case of the reason-to-exception test used a real OpenAIHook, so
it passed only because the failed connection lookup was swallowed. It is now
one table of reason, expected exception and whether cancellation is
requested, with a spec'd hook mock for every row.

…cstrings

The timeout param now keeps to what it bounds plus the execution_timeout
caveat, scoped to deferrable mode. The termination-reason-to-exception
mapping lives only in execute_complete, and the asynchronous cancellation
caveat only in _cancel_batch_quietly.